Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/app/api/auth/login/route.ts`:
- Around line 6-23: The route handler currently calls request.json() and
proceeds to auth without validating the payload; update the handler around the
request.json() call in the route (the code that extracts { email, password }) to
explicitly validate the parsed body: wrap request.json() in its own try/catch to
catch malformed JSON and return NextResponse.json({ error: "Invalid JSON" }, {
status: 400 }); then validate that email and password exist and are strings
(e.g., if (!email || typeof email !== "string" || !password || typeof password
!== "string") return NextResponse.json({ error: "Missing or invalid credentials"
}, { status: 400 });) before calling supabase.auth.signInWithPassword so
credential errors remain 400 and unexpected exceptions still fall through to the
existing 500 catch.

In `@src/app/api/auth/signup/route.ts`:
- Around line 6-23: The signup handler currently trusts await request.json() and
the destructured { email, password } which can throw or yield invalid payloads
and push malformed requests into the 500 catch; update the logic around
request.json(), validate the parsed body before calling supabase.auth.signUp
(ensure email and password exist, are strings, and optionally validate email
format and password length/constraints), return NextResponse.json({ error:
"Invalid request" }, { status: 400 }) for malformed JSON or invalid credentials,
and only let unexpected exceptions fall through to the existing 500 catch;
locate and modify the code around request.json(), the destructuring of { email,
password }, the call to supabase.auth.signUp, and the NextResponse error returns
to implement these checks.

In `@src/lib/hooks/useAuth.ts`:
- Around line 10-27: The supabase client is being recreated each render causing
the useEffect (which depends on supabase.auth) to re-run and repeatedly
subscribe; wrap createClient() in useMemo (e.g. const supabase = useMemo(() =>
createClient(), [])) to stabilize the instance, change the effect dependency to
[supabase], replace the getSession().then(...) call with
getSession().then(...).finally(() => setLoading(false)) to guarantee loading is
cleared, and keep the auth change listener via
supabase.auth.onAuthStateChange(...) with the same cleanup return () =>
subscription?.unsubscribe().

In `@src/middleware.ts`:
- Around line 26-29: The middleware currently awaits supabase.auth.getUser()
with no error handling which can throw and block requests; wrap the await
supabase.auth.getUser() call in a try/catch inside the middleware, ignore the
call's result (since it isn't used), and on error log the exception (e.g.,
console.error or your process logger) and proceed to return supabaseResponse so
transient auth failures don't break matched requests.
- Around line 33-42: Update the middleware matcher pattern in src/middleware.ts
(the "matcher" array entry) to exclude auth routes and additional static asset
extensions so supabase.auth.getUser() does not run for them; specifically adjust
the existing regex "/((?!_next/static|_next/image|favicon.ico|.*\\.svg).*)" to
also negative-match "/api/auth/login" and "/api/auth/signup" and file extensions
like .png, .jpg, .jpeg, .gif, .webp, .txt, .xml (and .svg if not already
covered), ensuring the middleware only runs for intended dynamic routes.

In `@supabase/config.toml`:
- Around line 154-157: site_url and additional_redirect_urls have mismatched
schemes which will break Supabase auth exact-match checks; update the entries so
their schemes match exactly (either change additional_redirect_urls to
"http://127.0.0.1:3000" to match site_url, or change site_url to
"https://127.0.0.1:3000" if you intend HTTPS), and ensure the host and port
remain identical for the values referenced by site_url and
additional_redirect_urls.

---

Nitpick comments:
In `@supabase/config.toml`:
- Around line 216-220: The config currently disables email confirmations
(enable_confirmations), disables secure password change
(secure_password_change), and sets a 1s resend interval (max_frequency) which
are safe only for local/testing; update these settings so they are either
documented as strictly local/testing and moved into a local-only config, or
parameterized behind environment-specific controls (e.g., require an explicit
DEV_ONLY env flag before allowing enable_confirmations=false,
secure_password_change=false, max_frequency="1s"); change defaults to secure
values for shared/staging/prod (enable_confirmations=true,
secure_password_change=true, reasonable max_frequency like "1m" or configurable)
and add a short comment near enable_confirmations / secure_password_change /
max_frequency warning that the relaxed values must not be used outside local dev
without explicit opt-in via an env variable.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/app/api/auth/login/route.ts`:
- Around line 47-48: There is an unmatched closing brace in the login route file
— remove the extra `}` that appears just before the final closing brace so the
function/block in src/app/api/auth/login/route.ts (the login route handler) has
balanced braces; keep the final `}` that ends the function/exports and delete
the stray closing brace immediately preceding it.
- Around line 13-27: The destructuring of body in the login route can throw when
body is null; before unpacking email and password (the const { email, password }
= body in route.ts inside the login handler), first check that body is a
non-null object (e.g. typeof body === "object" && body !== null) and return
NextResponse.json({ error: "Email and password are required" }, { status: 400 })
if it fails; only then destructure and run the existing string/emptiness checks
for email/password to ensure null JSON bodies yield a 400 rather than a 500.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/app/api/auth/signup/route.ts`:
- Around line 43-44: The current emailRegex and its use (emailRegex.test(email))
in the signup route are vulnerable to catastrophic backtracking; replace this
with a deterministic, linear-time validation: ensure exactly one '@' using
indexOf/lastIndexOf, verify non-empty local and domain parts, ensure domain
contains at least one '.' not at start/end, and reject any whitespace
characters; alternatively use a vetted library (e.g., validator.isEmail) and
call it from the same signup handler where emailRegex is referenced.

---

Duplicate comments:
In `@src/app/api/auth/signup/route.ts`:
- Line 71: The catch clause in the signup route's POST handler currently
declares an unused binding as "catch (error)" which triggers the linter; remove
the unused binding by changing the clause to "catch {", i.e. update the
try/catch in the POST handler (look for the "catch (error)" occurrence) so the
catch block has no parameter; no other logic changes are required.